home *** CD-ROM | disk | FTP | other *** search
- D. Crocker (UCLA-NMC)
- RFC 658, NIC 31161 (Oct. 25, 1974)
- Online file: [ISI]<DCROCKER>NAOLFD.TXT
-
- TELNET OUTPUT LINEFEED DISPOSITION
-
- 1. Command name and code
- NAOLFD 16
- (Negotiate About Output Linefeed Disposition)
-
- 2. Command meanings
- In the following, we are discussing a simplex connection, as described in
- the NAOL and NAOP Telnet Options.
- IAC DO NAOLFD
- The data sender requests or agrees to negotiate about output
- linefeed disposition with the data receiver. In the case where
- agreement has been reached and in the absence of further
- subnegotiations, the data receiver is assumed to be handling output
- linefeed considerations.
- IAC DON'T NAOLFD
- The data sender refuses to negotiate about output linefeed
- disposition with the data receiver, or demands a return to the
- unnegotiated default mode.
- IAC WILL NAOLFD
- The data receiver requests or agrees to negotiate about output
- linefeed disposition with the sender. In the case where agreement
- has been reached and in the absence of further subnegotiations, the
- data receiver alone is assumed to be handling output linefeed
- considerations.
- IAC WON'T NAOLFD
- The data receiver refuses to negotiate about output linefeed
- disposition, or demands a return to the unnegotiated default mode.
- IAC SB NAOLFD DS <8-bit value> IAC SE
- The data sender specifies, with the 8-bit value, which party should
- handle output linefeeds and what their disposition should be. The
- code for DS is 1.
- IAC SB NAOLFD DR <8-bit value> IAC SE
- The data receiver specifies, with the 8-bit value, which party
- should handle output linefeeds and what their disposition should
- be. The code for DR is 0.
-
- 3. Default
- DON'T NAOLFD/WON'T NAOLFD.
- In the default absence of negotiations concerning which party, data
- under or data receiver, is handling output linefeed considerations,
- neither party is required nor prohibited from handling linefeeds; but
- it is appropriate if at least the data receiver handles them, albeit
- primitively.
-
- 4. Motivation for the Option
- Please refer to section 4 of the NAOL and of the NAOLFD Telnet option
- descriptions.
-
- 5. Description of the Option
- The data sender and the data receiver use the 8-bit value along with DS
- and DR SB commands as follows:
-
- 8-bit value Meaning
-
- 0 Command sender suggests that he alone will handle
- linefeeds, for the connection.
- 1 to 250 Command sender suggests that the other party alone
- should handle linefeeds, but suggests that a delay
- of the indicated value be used. The value is the
- number of character-times to wait or number of
- NULs to insert in the data stream before sending
- the next data character. (See qualifications, below.)
- 251 Not allowed, in order to be compatible with
- related Telnet options.
- 252 Command sender suggests that the other party alone
- handle linefeeds, but suggests that they be discarded.
- 253 Command sender suggests that the other party alone
- should handle linefeeds, but suggests that
- linefeeds be simulated.
- 254 Command sender suggests that the other party alone
- should handle output linefeeds but suggests
- waiting for a character to be transmitted (on the
- other simplex connection) before sending more
- data. (See qualifications, below.) Note that, due
- to the assynchrony of the two simplex connections,
- phase problems can occur with this option.
- 255 Command sender suggests that the other party alone
- should handle output linefeeds and suggests
- nothing about how it should be done.
-
- The guiding rules are that:
-
- 1) if neither data receiver nor data sender wants to handle output
- linefeeds, the data receiver must do it, and
- 2) if both data receiver and data sender want to handle output linefeed
- disposition, the data sender gets to do it.
-
- The reasoning for the former rule is that if neither wants to do it, then
- the default in the NAOLFD option dominates. If both want to do it, the
- sender, who is presumed to have special knowledge about the data, should
- be allowed to do it, taking into account any suggestions the receiver may
- make. Simulation is defined as the replacement of the linefeed character
- by new-line (see following) and enough blanks to move the print head (or
- line pointer) to the same lateral position it occupied just prior to
- receiving the linefeed. To avoid infinite recursion, such simulation is
- allowed only for linefeed characters that are not immediately preceded by
- carriage-returns (that is, part of a Telnet new-line combination). It is
- assumed that linefeed simulation will be necessary for printers that do
- not have a separate linefeed (like the IBM 2741); in this case,
- end-of-line character padding can be specified through NAOCRD. Any
- padding (0 < <8-bit-value> < 251) of linefeed characters is to be done
- for ALL linefeed characters.
-
- NOTE: Delays, controlled by the data sender, must consist of NUL
- characters inserted immediately after the character. This is necessary
- due to the assynchrony of network transmissions. Additionally, due to
- the presence of the Telnet end-of-line convention, it may be necessary to
- add carriage-return padding or delay after the associated linefeed (see
- NAOCRD Telnet option). As with all option negotiations, neither party
- should suggest a state already in effect except to refuse to negotiate;
- changes should be acknowledged; and once refused, an option should not be
- resuggested until "something changes" (e.g., another process starts). At
- any time, either party can disable further negotiation by giving the
- appropriate WON'T NAOLFD or DON'T NAOLFD command.
-